The Fatted Calf

home *** CD-ROM | disk | FTP | other *** search

/ The Fatted Calf / The Fatted Calf.iso / Applications / Graphics / GraphicsWorkshop / Source / Formats / 5.0spec next >

Wrap

Text File | 1992-09-23 | 102.0 KB | 2,282 lines

An Aldus/Microsoft Technical Memorandum: 8/8/88 Page 1 Preface This memorandum has been prepared jointly by Aldus and Microsoft in conjunction with leading scanner vendors and other interested parties. This document does not represent a commitment on the part of either Microsoft or Aldus to provide support for this file format in any application. When responding to specific issues raised in this memo, or when requesting additional tag or field assignments, please address your correspondence to either: Developers' Desk Windows Marketing Group Aldus Corporation Microsoft Corporation 411 First Ave. South 16011 NE 36th Way Suite 200 Box 97017 Seattle, WA 98104 Redmond, WA 98073-9717 (206) 622-5500 (206) 882-8080 Revision Notes This revision replaces "TIFF Revision 4." Sections in italics are new or substantially changed in this revision. Also new, but not in italics, are Appendices F, G, and H. The major enhancements in TIFF 5.0 are: 1. Compression of grayscale and color images, for better disk space utilization. See Appendix F. 2. TIFF Classes - restricted TIFF subsets that can simplify the job of the TIFF implementor. You may wish to scan Appendix G before reading the rest of this document. In fact, you may want to use Appendix G as your main guide, and refer back to the main body of the specification as needed for details concerning TIFF structures and field definitions. 3. Support for "palette color" images. See the TIFF Class P description in Appendix G, and the new ColorMap field description. 4. Two new tags that can be used to more fully define the characteristics of full color RGB data, and thereby potentially improve the quality of color image reproduction. See Appendix H. The organization of the document has also changed slightly. In particular, the tags are listed in alphabetical order, within several categories, in the main body of the specification. As always, every attempt has been made to add functionality in such a way as to minimize incompatibility problems with older TIFF software. In particular, many TIFF 5.0 files will be readable even by older applications that assume TIFF 4.0 or an earlier version of the specification. One exception is with files that use the new TIFF 5.0 LZW compression scheme. Old applications will have to give up in this case, of course, and will do so "gracefully" if they have been following the rules. We are grateful to all of the draft reviewers for their suggestions. Especially helpful were Herb Weiner of Kitchen Wisdom Publishing Company, Brad Pillow of TrueVision, and engineers from Hewlett Packard and Quark. Chris Sears of Magenta Graphics provided information which is included as Appendix H. Abstract This document describes TIFF, a tag based file format that is designed to promote the interchange of digital image data. The fields were defined primarily with desktop publishing and related applications in mind, although it is possible that other sorts of imaging applications may find TIFF to be useful. The general scenario for which TIFF was invented assumes that applications software for scanning or painting creates a TIFF file, which can then be read and incorporated into a "document" or "publication" by an application such as a desktop publishing package. TIFF is not a printer language or page description language, nor is it intended to be a general document interchange standard. The primary design goal was to provide a rich environment within which the exchange of image data between application programs can be accomplished. This richness is required in order to take advantage of the varying capabilities of scanners and similar devices. TIFF is therefore designed to be a superset of existing image file formats for "desktop" scanners (and paint programs and anything else that produces images with pixels in them) and will be enhanced on a continuing basis as new capabilities arise. A high priority has been given to structuring the data in such a way as to minimize the pain of future additions. TIFF was designed to be an extensible interchange format. Although TIFF is claimed to be in some sense a rich format, it can easily be used for simple scanners and applications as well, since the application developer need only be concerned with the capabilities that he requires. TIFF is intended to be independent of specific operating systems, filing systems, compilers, and processors. The only significant assumption is that the storage medium supports something like a "file," defined as a sequence of 8-bit bytes, where the bytes are numbered from 0 to N. The largest possible TIFF file is 2**32 bytes in length. Since TIFF uses pointers (byte offsets) quite liberally, a TIFF file is most easily read from a random access device such as a hard disk or flexible diskette, although it should be possible to read and write TIFF files on magnetic tape. The recommended MS-DOS, UNIX, and OS/2 file extension for TIFF files is ".TIF." The recommended Macintosh filetype is "TIFF". Suggestions for conventions in other computing environments are welcome. 1) Structure In TIFF, individual fields are identified with a unique tag. This allows particular fields to be present or absent from the file as required by the application. For an explanation of the rationale behind using a tag structure format, see Appendix A. A TIFF file begins with an 8-byte "image file header" that points to one or more "image file directories." The image file directories contain information about the images, as well as pointers to the actual image data. See Figure 1. We will now describe these structures in more detail. Image file header A TIFF file begins with an 8-byte image file header, containing the following information: Bytes 0-1: The first word of the file specifies the byte order used within the file. Legal values are: "II" (hex 4949) "MM" (hex 4D4D) In the "II" format, byte order is always from least significant to most significant, for both 16-bit and 32-bit integers. In the "MM" format, byte order is always from most significant to least significant, for both 16-bit and 32-bit integers. In both formats, character strings are stored into sequential byte locations. All TIFF readers should support both byte orders - see Appendix G. Bytes 2-3 The second word of the file is the TIFF "version number." This number, 42 (2A in hex), is not to be equated with the current Revision of the TIFF specification. In fact, the TIFF version number (42) has never changed, and probably never will. If it ever does, it means that TIFF has changed in some way so radical that a TIFF reader should give up immediately. The number 42 was chosen for its deep philosophical significance. It can and should be used as additional verification that this is indeed a TIFF file. A TIFF file does not have a real version/revision number. This was an explicit, conscious design decision. In many file formats, fields take on different meanings depending on a single version number. The problem is that as the file format "ages," it becomes increasingly difficult to document which fields mean what in a given version, and older software usually has to give up if it encounters a file with a newer version number. We wanted TIFF fields to have a permanent and well-defined meaning, so that "older" software can usually read "newer" TIFF files. The bottom line is lower software release costs and more reliable software. Bytes 4-7 This long word contains the offset (in bytes) of the first Image File Directory. The directory may be at any location in the file after the header but must begin on a word boundary. In particular, an Image File Directory may follow the image data it describes. Readers must simply follow the pointers, wherever they may lead. (The term "byte offset" is always used in this document to refer to a location with respect to the beginning of the file. The first byte of the file has an offset of 0.) Image file directory An Image File Directory (IFD) consists of a 2-byte count of the number of entries (i.e., the number of fields), followed by a sequence of 12-byte field entries, followed by a 4-byte offset of the next Image File Directory (or 0 if none). Do not forget to write the 4 bytes of 0 after the last IFD. Each 12-byte IFD entry has the following format: Bytes 0-1 contain the Tag for the field. Bytes 2-3 contain the field Type. Bytes 4-7 contain the Length ("Count" might have been a better term) of the field. Bytes 8-11 contain the Value Offset, the file offset (in bytes) of the Value for the field. The Value is expected to begin on a word boundary; the corresponding Value Offset will thus be an even number. This file offset may point to anywhere in the file, including after the image data. The entries in an IFD must be sorted in ascending order by Tag. Note that this is not the order in which the fields are described in this document. For a numerically ordered list of tags, see Appendix E. The Values to which directory entries point need not be in any particular order in the file. In order to save time and space, the Value Offset is interpreted to contain the Value instead of pointing to the Value if the Value fits into 4 bytes. If the Value is less than 4 bytes, it is left-justified within the 4-byte Value Offset, i.e., stored in the lower-numbered bytes. Whether or not the Value fits within 4 bytes is determined by looking at the Type and Length of the field. The Length is specified in terms of the data type, not the total number of bytes. A single 16-bit word (SHORT) has a Length of 1, not 2, for example. The data types and their lengths are described below: 1 = BYTE An 8-bit unsigned integer. 2 = ASCII 8-bit bytes that store ASCII codes; the last byte must be null. 3 = SHORT A 16-bit (2-byte) unsigned integer. 4 = LONG A 32-bit (4-byte) unsigned integer. 5 = RATIONAL Two LONG's: the first represents the numerator of a fraction, the second the denominator. The value of the Length part of an ASCII field entry includes the null. If padding is necessary, the Length does not include the pad byte. Note that there is no "count byte," as there is in Pascal-type strings. The Length part of the field takes care of that. The null is not strictly necessary, but may make things slightly simpler for C programmers. The reader should check the type to ensure that it is what he expects. TIFF currently allows more than 1 valid type for some fields. For example, ImageWidth and ImageLength were specified as having type SHORT. Very large images with more than 64K rows or columns are possible with some devices even now. Rather than add parallel LONG tags for these fields, it is cleaner to allow both SHORT and LONG for ImageWidth and similar fields. See Appendix G for specific recommendations. Note that there may be more than one IFD. Each IFD is said to define a "subfile." One potential use of subsequent subfiles is to describe a "sub-image" that is somehow related to the main image, such as a reduced resolution version of the image. If you have not already done so, you may wish to turn to Appendix G to study the sample TIFF images. 2) Definitions Note that the TIFF structure as described in the previous section is not specific to imaging applications in any way. It is only the definitions of the fields themselves that jointly describe an image. Before we begin defining the fields, we will define some basic concepts. An image is defined to be a rectangular array of "pixels," each of which consists of one or more "samples." With monochromatic data, we have one sample per pixel, and "sample" and "pixel" can be used interchangeably. RGB color data contains three samples per pixel. 3) The Fields This section describes the fields defined in this version of TIFF. More fields may be added in future versions - if possible they will be added in such a way so as not to break old software that encounters a newer TIFF file. The documentation for each field contains the name of the field (quite arbitrary, but convenient), the Tag value, the field Type, the Number of Values (N) expected, comments describing the field, and the default, if any. Readers must assume the default value if the field does not exist. "No default" does not mean that a TIFF writer should not pay attention to the tag. It simply means that there is no default. If the writer has reason to believe that readers will care about the value of this field, the writer should write the field with the appropriate value. TIFF readers can do whatever they want if they encounter a missing "no default" field that they care about, short of refusing to import the file. For example, if a writer does not write out a PhotometricInterpretation field, some applications will interpret the image "correctly," and others will display the image inverted. This is not a good situation, and writers should be careful not to let it happen. The fields are grouped into several categories: basic, informational, facsimile, document storage and retrieval, and no longer recommended. A future version of the specification may pull some of these categories into separate companion documents. Many fields are described in this document, but most are not "required." See Appendix G for a list of required fields, as well as examples of how to combine fields into valid and useful TIFF files. Basic Fields Basic fields are fields that are fundamental to the pixel architecture or visual characteristics of an image. BitsPerSample Tag = 258 (102) Type = SHORT N = SamplesPerPixel Number of bits per sample. Note that this tag allows a different number of bits per sample for each sample corresponding to a pixel. For example, RGB color data could use a different number of bits per sample for each of the three color planes. Most RGB files will have the same number of BitsPerSample for each sample. Even in this case, be sure to include all three entries. Writing "8" when you mean "8,8,8" sets a bad precedent for other fields. Default = 1. See also SamplesPerPixel. ColorMap Tag = 320 (140) Type = SHORT N = 3 * (2**BitsPerSample) This tag defines a Red-Green-Blue color map for palette color images. The palette color pixel value is used to index into all 3 subcurves. For example, a Palette color pixel having a value of 0 would be displayed according to the 0th entry of the Red, Green, and Blue subcurves. The subcurves are stored sequentially. The Red entries come first, followed by the Green entries, followed by the Blue entries. The length of each subcurve is 2**BitsPerSample. A ColorMap entry for an 8-bit Palette color image would therefore have 3 * 256 entries. The width of each entry is 16 bits, as implied by the type of SHORT. 0 represents the minimum intensity, and 65535 represents the maximum intensity. Black is represented by 0,0,0, and white by 65535, 65535, 65535. The purpose of the color map is to act as a "lookup" table mapping pixel values from 0 to 2**BitsPerSample-1 into RGB triplets. The ColorResponseCurves field may be used in conjunction with ColorMap to further refine the meaning of the RGB triplets in the ColorMap. However, the ColorResponseCurves default should be sufficient in most cases. See also PhotometricInterpretation - palette color. No default. ColorMap must be included in all palette color images. ColorResponseCurves Tag = 301 (12D) Type = SHORT N = 3 * (2**BitsPerSample) This tag defines three color response curves, one each for Red, Green and Blue color information. The Red entries come first, followed by the Green entries, followed by the Blue entries. The length of each subcurve is 2**BitsPerSample, using the BitsPerSample value corresponding to the respective primary. The width of each entry is 16 bits, as implied by the type of SHORT. 0 represents the minimum intensity, and 65535 represents the maximum intensity. Black is represented by 0,0,0, and white by 65535, 65535, 65535. Therefore, a ColorResponseCurve entry for RGB data where each of the samples is 8 bits deep would have 3 * 256 entries, each consisting of a SHORT. The purpose of the color response curves is to refine the content of RGB color images. See Appendix H, section VII, for further information. Default: curves based on the NTSC recommended gamma of 2.2. Compression Tag = 259 (103) Type = SHORT N = 1 1 = No compression, but pack data into bytes as tightly as possible, with no unused bits except at the end of a row. The bytes are stored as an array of type BYTE, for BitsPerSample <= 8, SHORT if BitsPerSample > 8 and <= 16, and LONG if BitsPerSample > 16 and <= 32. The byte ordering of data >8 bits must be consistent with that specified in the TIFF file header (bytes 0 and 1). "II" format files will have the least significant bytes preceeding the most significant bytes while "MM" format files will have the opposite. If the number of bits per sample is not a power of 2, and you are willing to give up some space for better performance, you may wish to use the next higher power of 2. For example, if your data can be represented in 6 bits, you may wish to specify that it is 8 bits deep. Rows are required to begin on byte boundaries. The number of bytes per row is therefore (ImageWidth * SamplesPerPixel * BitsPerSample + 7) / 8, assuming integer arithmetic, for PlanarConfiguration=1. Bytes per row is (ImageWidth * BitsPerSample + 7) / 8 for PlanarConfiguration=2. Some graphics systems want rows to be word- or double-word- aligned. Uncompressed TIFF rows will need to be copied into word- or double-word-padded row buffers before being passed to the graphics routines in these environments. 2 = CCITT Group 3 1-Dimensional Modified Huffman run length encoding. See Appendix B: "Data Compression -- Scheme 2." BitsPerSample must be 1, since this type of compression is defined only for bilevel images. When you decompress data that has been compressed by Compression=2, you must translate white runs into 0's and black runs into 1's. Therefore, the normal PhotometricInterpretation for those compression types is 0 (WhiteIsZero). If a reader encounters a PhotometricInterpretation of 1 (BlackIsZero) for such an image, the image should be displayed and printed with black and white reversed. 5 = LZW Compression, for grayscale, mapped color, and full color images. See Appendix F. 32773 = PackBits compression, a simple byte oriented run length scheme for 1-bit images. See Appendix C. Data compression only applies to raster image data, as pointed to by StripOffsets. All other TIFF information is unaffected. Default = 1. GrayResponseCurve Tag = 291 (123) Type = SHORT N = 2**BitsPerSample The purpose of the gray response curve and the gray units is to provide more exact photometric interpretation information for gray scale image data, in terms of optical density. The GrayScaleResponseUnits specifies the accuracy of the information contained in the curve. Since optical density is specified in terms of fractional numbers, this tag is necessary to know how to interpret the stored integer information. For example, if GrayScaleResponseUnits is set to 4 (ten-thousandths of a unit), and a GrayScaleResponseCurve number for gray level 4 is 3455, then the resulting actual value is 0.3455. Optical densitometers typically measure densities within the range of 0.0 to 2.0. If the gray scale response curve is known for the data in the TIFF file, and if the gray scale response of the output device is known, then an intelligent conversion can be made between the input data and the output device. For example, the output can be made to look just like the input. In addition, if the input image lacks contrast (as can be seen from the response curve), then appropriate contrast enhancements can be made. The purpose of the gray scale response curve is to act as a "lookup" table mapping values from 0 to 2**BitsPerSample-1 into specific density values. The 0th element of the GrayResponseCurve array is used to define the gray value for all pixels having a value of 0, the 1st element of the GrayResponseCurve array is used to define the gray value for all pixels having a value of 1, and so on, up to 2**BitsPerSample-1. If your data is "really," say, 7-bit data, but you are adding a 1-bit pad to each pixel to turn it into 8-bit data, everything still works: If the data is high-order justified, half of your GrayResponseCurve entries (the odd ones, probably) will never be used, but that doesn't hurt anything. If the data is low-order justified, your pixel values will be between 0 and 127, so make your GrayResponseCurve accordingly. What your curve does from 128 to 255 doesnt matter. Note that low-order justification is probably not a good idea, however, since not all applications look at GrayResponseCurve. Note also that LZW compression yields the same compression ratio regardless of whether the data is high-order or low-order justified. It is permissable to have a GrayResponseCurve even for bilevel (1-bit) images. The GrayResponseCurve will have 2 values. It should be noted, however, that TIFF B readers are not required to pay attention to GrayResponseCurves in TIFF B files. See Appendix G. If both GrayResponseCurve and PhotometricInterpretation fields exist in the IFD, GrayResponseCurve values override the PhotometricInterpretation value. But it is a good idea to write out both, since some applications do not yet pay attention to the GrayResponseCurve. Writers may wish to purchase a Kodak Reflection Density Guide, catalog number 146 5947, available for $10 or so at prepress supply houses, to help them figure out reasonable density values for their scanner or frame grabber. If that sounds like too much work, we recommend a curve that is linear in intensity/reflectance. To compute reflectance from density: R = 1 / pow(10,D). To compute density from reflectance: D = log10 (1/R). A typical 4-bit GrayResponseCurve may look therefore something like: 2000, 1177, 875, 699, 574, 477, 398, 331, 273, 222, 176, 135, 97, 62, 30, 0, assuming GrayResponseUnit=3. Such a curve would be consistent with PhotometricInterpretation=1. See also GrayResponseUnit, PhotometricInterpretation, ColorMap. GrayResponseUnit Tag = 290 (122) Type = SHORT N = 1 1 = Number represents tenths of a unit. 2 = Number represents hundredths of a unit. 3 = Number represents thousandths of a unit. 4 = Number represents ten-thousandths of a unit. 5 = Number represents hundred-thousandths of a unit. Modifies GrayResponseCurve. See also GrayResponseCurve. For historical reasons, the default is 2. However, for greater accuracy, we recommend using 3. ImageLength Tag = 257 (101) Type = SHORT or LONG N = 1 The image's length (height) in pixels (Y: vertical). The number of rows (sometimes described as "scan lines") in the image. See also ImageWidth. No default. ImageWidth Tag = 256 (100) Type = SHORT or LONG N = 1 The image's width, in pixels (X: horizontal). The number of columns in the image. See also ImageLength. No default. NewSubfileType Tag = 254 (FE) Type = LONG N = 1 Replaces the old SubfileType field, due to limitations in the definition of that field. A general indication of the kind of data that is contained in this subfile. This field is made up of a set of 32 flag bits. Unused bits are expected to be 0. Bit 0 is the low-order bit. Currently defined values are: Bit 0 is 1 if the image is a reduced resolution version of another image in this TIFF file; else the bit is 0. Bit 1 is 1 if the image is a single page of a multi-page image (see the PageNumber tag description); else the bit is 0. Bit 2 is 1 if the image defines a transparency mask for another image in this TIFF file. The PhotometricInterpretation value must be 4, designating a transparency mask. These values have been defined as bit flags because they are pretty much independent of each other. For example, it be useful to have four images in a single TIFF file: a full resolution image, a reduced resolution image, a transparency mask for the full resolution image, and a transparency mask for the reduced resolution image. Each of the four images would have a different value for the NewSubfileType field. Default is 0. PhotometricInterpretation Tag = 262 (106) Type = SHORT N = 1 0 = For bilevel and grayscale images: 0 is imaged as white. 2**BitsPerSample-1 is imaged as black. If GrayResponseCurve exists, it overrides the PhotometricInterpretation value, although it is safer to make them match, since some old applications may still be ignoring GrayResponseCurve. This is the normal value for Compression=2. 1 = For bilevel and grayscale images: 0 is imaged as black. 2**BitsPerSample-1 is imaged as white. If GrayResponseCurve exists, it overrides the PhotometricInterpretation value, although it is safer to make them match, since some old applications may still be ignoring GrayResponseCurve. If this value is specified for Compression=2, the image should display and print reversed. 2 = RGB. In the RGB model, a color is described as a combination of the three primary colors of light (red, green, and blue) in particular concentrations. For each of the three samples, 0 represents minimum intensity, and 2**BitsPerSample - 1 represents maximum intensity. Thus an RGB value of (0,0,0) represents black, and (255,255,255) represents white, assuming 8-bit samples. For PlanarConfiguration = 1, the samples are stored in the indicated order: first Red, then Green, then Blue. For PlanarConfiguration = 2, the StripOffsets for the sample planes are stored in the indicated order: first the Red sample plane StripOffsets, then the Green plane StripOffsets, then the Blue plane StripOffsets. The ColorResponseCurves field may be used to globally refine or alter the color balance of an RGB image without having to change the values of the pixels themselves. 3="Palette color." In this mode, a color is described with a single sample. The sample is used as an index into ColorMap. The sample is used to index into each of the red, green and blue curve tables to retrieve an RGB triplet defining an actual color. When this PhotometricInterpretation value is used, the color response curves must also be supplied. SamplesPerPixel must be 1. 4 = Transparency Mask. This means that the image is used to define an irregularly shaped region of another image in the same TIFF file. SamplesPerPixel and BitsPerSample must be 1. PackBits compression is recommended. The 1-bits define the interior of the region; the 0-bits define the exterior of the region. The Transparency Mask must have the same ImageLength and ImageWidth as the main image. A reader application can use the mask to determine which parts of the image to display. Main image pixels that correspond to 1-bits in the transparency mask are imaged to the screen or printer, but main image pixels that correspond to 0-bits in the mask are not displayed or printed. It is possible to generalize the notion of a transparency mask to include partial transparency, but it is not clear that such information would be useful to a desktop publishing program. No default. That means that if you care if your image is displayed and printed as "normal" vs "inverted," you must write out this field. Do not rely on applications defaulting to what you want! PhotometricInterpretation = 1 is recommended for bilevel (except for Compression=2) and grayscale images, due to popular user interfaces for changing the brightness and contrast of images. PlanarConfiguration Tag = 284 (11C) Type = SHORT N = 1 1 = The sample values for each pixel are stored contiguously, so that there is a single image plane. See PhotometricInterpretation to determine the order of the samples within the pixel data. So, for RGB data, the data is stored RGBRGBRGB...and so on. 2 = The samples are stored in separate "sample planes." The values in StripOffsets and StripByteCounts are then arranged as a 2-dimensional array, with SamplesPerPixel rows and StripsPerImage columns. (All of the columns for row 0 are stored first, followed by the columns of row 1, and so on.) PhotometricInterpretation describes the type of data that is stored in each sample plane. For example, RGB data is stored with the Red samples in one sample plane, the Green in another, and the Blue in another. If SamplesPerPixel is 1, PlanarConfiguration is irrelevant, and should not be included. Default is 1. See also BitsPerSample, SamplesPerPixel. Predictor Tag = 317 (13D) Type = SHORT N = 1 To be used when Compression=5 (LZW). See Appendix F. 1 = No prediction scheme used before coding. Default is 1. ResolutionUnit Tag = 296 (128) Type = SHORT N = 1 To be used with XResolution and YResolution. 1 = No absolute unit of measurement. Used for images that may have a non-square aspect ratio, but no meaningful absolute dimensions. The drawback of ResolutionUnit=1 is that different applications will import the image at different sizes. Even if the decision is quite arbitrary, it might be better to use dots per inch or dots per centimeter, and pick XResolution and YResolution such that the aspect ratio is correct and the maximum dimension of the image is about four inches (the "four" is quite arbitrary.) 2 = Inch. 3 = Centimeter. Default is 2. See also XResolution, YResolution. RowsPerStrip Tag = 278 (116) Type = SHORT or LONG N = 1 The number of rows per strip. The image data is organized into strips for fast access to individual rows when the data is compressed - though this field is valid even if the data is not compressed. RowsPerStrip and ImageLength together tell us the number of strips in the entire image. The equation is StripsPerImage = (ImageLength + RowsPerStrip - 1) / RowsPerStrip, assuming integer arithmetic. Note that either SHORT or LONG values can be used to specify RowsPerStrip. SHORT values may be used for small TIFF files. It should be noted, however, that earlier TIFF specification revisions required LONG values and that some software may not expect SHORT values. See Appendix G for further recommendations. Default is 2**32 - 1, which is effectively infinity. That is, the entire image is one strip. We do not recommend a single strip, however. Choose RowsPerStrip such that each strip is about 8K bytes, even if the data is not compressed, since it makes buffering simpler for readers. The "8K" part is pretty arbitrary, but seems to work well. See also ImageLength, StripOffsets, StripByteCounts. SamplesPerPixel Tag = 277 (115) Type = SHORT N = 1 The number of samples per pixel. SamplesPerPixel is 1 for bilevel, grayscale, and palette color images. SamplesPerPixel is 3 for RGB images. Default = 1. See also BitsPerSample, PhotometricInterpretation. StripByteCounts Tag = 279 (117) Type = SHORT or LONG N = StripsPerImage for PlanarConfiguration equal to 1. = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2 For each strip, the number of bytes in that strip. The existence of this field greatly simplifies the chore of buffering compressed data, if the strip size is reasonable. No default. See also StripOffsets, RowsPerStrip. StripOffsets Tag = 273 (111) Type = SHORT or LONG N = StripsPerImage for PlanarConfiguration equal to 1. = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2 For each strip, the byte offset of that strip. The offset is specified with respect to the beginning of the TIFF file. Note that this implies that each strip has a location independent of the locations of other strips. This feature may be useful for editing applications. This field is the only way for a reader to find the image data, and hence must exist. Note that either SHORT or LONG values can be used to specify the strip offsets. SHORT values may be used for small TIFF files. It should be noted, however, that earlier TIFF specifications required LONG strip offsets and that some software may not expect SHORT values. See Appendix G for further recommendations. No default. See also StripByteCounts, RowsPerStrip. XResolution Tag = 282 (11A) Type = RATIONAL N = 1 The number of pixels per ResolutionUnit in the X direction, i.e., in the ImageWidth direction. It is, of course, not mandatory that the image be actually printed at the size implied by this parameter. It is up to the application to use this information as it wishes. No default. See also YResolution, ResolutionUnit. YResolution Tag = 283 (11B) Type = RATIONAL N = 1 The number of pixels per ResolutionUnit in the Y direction, i.e., in the ImageLength direction. No default. See also XResolution, ResolutionUnit. Informational Fields Informational fields are fields that can provide useful information to a user, such as where the image came from. Most are ASCII fields. An application could have some sort of "More Info..." dialog box to display such information. Artist Tag = 315 (13B) Type = ASCII Person who created the image. If you need to attach a Copyright notice to an image, this is the place to do it. In fact, you may wish to write out the contents of the field immediately after the 8-byte TIFF header. Just make sure your IFD and field pointers are set accordingly, and you're all set. DateTime Tag = 306 (132) Type = ASCII N = 20 Date and time of image creation. Use the format "YYYY:MM:DD HH:MM:SS", with hours on a 24-hour clock, and one space character between the date and the time. The length of the string, including the null, is 20 bytes. HostComputer Tag = 316 (13C) Type = ASCII "ENIAC", or whatever. See also Make, Model, Software. ImageDescription Tag = 270 (10E) Type = ASCII For example, a user may wish to attach a comment such as "1988 company picnic" to an image. It has been suggested that this is what the newspaper and magazine industry calls a "slug." Make Tag = 271 (10F) Type = ASCII Manufacturer of the scanner, video digitizer, or whatever. See also Model, Software. Model Tag = 272 (110) Type = ASCII The model name/number of the scanner, video digitizer, or whatever. This tag is intended for user information only. See also Make, Software. Software Tag = 305 (131) Type = ASCII Name and release number of the software package that created the image. This tag is intended for user information only. See also Make, Model. Facsimile Fields Facsimile fields may be useful if you are using TIFF to store facsimile messages in "raw" form. They are not recommended for use in interchange with desktop publishing applications. Compression (a basic tag) Tag = 259 (103) Type = SHORT N = 1 3 = Facsimile-compatible CCITT Group 3, exactly as specified in "Standardization of Group 3 facsimile apparatus for document transmission," Recommendation T.4, Volume VII, Fascicle VII.3, Terminal Equipment and Protocols for Telematic Services, The International Telegraph and Telephone Consultative Committee (CCITT), Geneva, 1985, pages 16 through 31. Each strip must begin on a byte boundary. (But recall that an image can be a single strip.) Rows that are not the first row of a strip are not required to begin on a byte boundary. The data is stored as bytes, not words - byte-reversal is not allowed. See the Group3Options field for Group 3 options such as 1D vs 2D coding. 4 = Facsimile-compatible CCITT Group 4, exactly as specified in "Facsimile Coding Schemes and Coding Control Functions for Group 4 Facsimile Apparatus," Recommendation T.6, Volume VII, Fascicle VII.3, Terminal Equipment and Protocols for Telematic Services, The International Telegraph and Telephone Consultative Committee (CCITT), Geneva, 1985, pages 40 through 48. Each strip must begin on a byte boundary. Rows that are not the first row of a strip are not required to begin on a byte boundary. The data is stored as bytes, not words. See the Group4Options field for Group 4 options. Group3Options Tag = 292 (124) Type = LONG N = 1 See Compression=3. This field is made up of a set of 32 flag bits. Unused bits are expected to be 0. Bit 0 is the low-order bit. It is probably not safe to try to read the file if any bit of this field is set that you don't know the meaning of. Bit 0 is 1 for 2-dimensional coding (else 1-dimensional is assumed). For 2-D coding, if more than one strip is specified, each strip must begin with a 1-dimensionally coded line. That is, RowsPerStrip should be a multiple of "Parameter K" as documented in the CCITT specification. Bit 1 is 1 if uncompressed mode is used. Bit 2 is 1 if fill bits have been added as necessary before EOL codes such that EOL always ends on a byte boundary, thus ensuring an eol-sequence of a 1 byte preceded by a zero nibble: xxxx-0000 0000-0001. Default is 0, for basic 1-dimensional coding. See also Compression. Group4Options Tag = 293 (125) Type = LONG N = 1 See Compression=4. This field is made up of a set of 32 flag bits. Unused bits are expected to be 0. Bit 0 is the low-order bit. It is probably not safe to try to read the file if any bit of this field is set that you don't know the meaning of. Gray scale and color coding schemes are under study, and will be added when finalized. For 2-D coding, each strip is encoded as if it were a separate image. In particular, each strip begins on a byte boundary; and the coding for the first row of a strip is encoded independently of the previous row, using horizontal codes, as if the previous row is entirely white. Each strip ends with the 24-bit end-of- facsimile block (EOFB). Bit 0 is unused. Bit 1 is 1 if uncompressed mode is used. Default is 0, for basic 2-dimensional binary compression. See also Compression. Document Storage and Retrieval Fields These fields may be useful for document storage and retrieval applications. They are not recommended for use in interchange with desktop publishing applications. DocumentName Tag = 269 (10D) Type = ASCII The name of the document from which this image was scanned. See also PageName. PageName Tag = 285 (11D) Type = ASCII The name of the page from which this image was scanned. See also DocumentName. No default. PageNumber Tag = 297 (129) Type = SHORT N = 2 This tag is used to specify page numbers of a multiple page (e.g. facsimile) document. Two SHORT values are specified. The first value is the page number; the second value is the total number of pages in the document. Note that pages need not appear in numerical order. The first page is 0 (zero). No default. XPosition Tag = 286 (11E) Type = RATIONAL The X offset of the left side of the image, with respect to the left side of the page, in ResolutionUnits. No default. See also YPosition. YPosition Tag = 287 (11F) Type = RATIONAL The Y offset of the top of the image, with respect to the top of the page, in ResolutionUnits. In the TIFF coordinate scheme, the positive Y direction is down, so that YPosition is always positive. No default. See also XPosition. No Longer Recommended These fields are not recommended except perhaps for local use. They should not be used for image interchange. They have either been superseded by other fields, have been found to have serious drawbacks, or are simply not as useful as once thought. They may be dropped entirely from a future revision of the specification. CellLength Tag = 265 (109) Type = SHORT N = 1 The length, in 1-bit samples, of the dithering/halftoning matrix. Assumes that Threshholding = 2. This field, plus CellWidth and Threshholding, are problematic because they cannot safely be used to reverse-engineer grayscale image data out of dithered/halftoned black-and-white data, which is their only plausible purpose. The only "right" way to do it is to not bother with anything like these fields, and instead write some sophisticated pattern-matching software that can handle screen angles that are not multiples of 45 degrees, and other such challenging dithered/halftoned data. So we do not recommend trying to convert dithered or halftoned data into grayscale data. Dithered and halftoned data require careful treatment to avoid "stretch marks," but it can be done. If you want grayscale images, get them directly from the scanner or frame grabber or whatever. No default. See also Threshholding. CellWidth Tag = 264 (108) Type = SHORT N = 1 The width, in 1-bit samples, of the dithering/halftoning matrix. No default. See also Threshholding. See the comments for CellLength. FillOrder Tag = 266 (10A) Type = SHORT N = 1 The order of data values within a byte. 1 = most significant bits of the byte are filled first. That is, data values (or code words) are ordered from high order bit to low order bit within a byte. 2 = least significant bits are filled first. Since little interest has been expressed in least-significant fill order to date, and since it is easy and inexpensive for writers to reverse bit order (use a 256-byte lookup table), we recommend FillOrder=2 for private (non-interchange) use only. Default is FillOrder = 1. FreeByteCounts Tag = 289 (121) Type = LONG For each "free block" in the file, the number of bytes in the block. TIFF readers can ignore FreeOffsets and FreeByteCounts if present. FreeOffsets and FreeByteCounts do not constitute a remapping of the logical address space of the file. Since this information can be generated by scanning the IFDs, StripOffsets, and StripByteCounts, FreeByteCounts and FreeOffsets are not needed. In addition, it is not clear what should happen if FreeByteCounts and FreeOffsets exist in more than one IFD. See also FreeOffsets. FreeOffsets Tag = 288 (120) Type = LONG For each "free block" in the file, its byte offset. See also FreeByteCounts. MaxSampleValue Tag = 281 (119) Type = SHORT N = SamplesPerPixel The maximum used sample value. For example, if the image consists of 6-bit data low-order-justified into 8-bit bytes, MaxSampleValue will be no greater than 63. This is field is not to be used to affect the visual appearance of the image when displayed. Nor should the values of this field affect the interpretation of any other field. Use it for statistical purposes only. Default is 2**(BitsPerSample) - 1. MinSampleValue Tag = 280 (118) Type = SHORT N = SamplesPerPixel The minimum used sample value. This field is not to be used to affect the visual appearance of the image when displayed. See the comments for MaxSampleValue. Default is 0. SubfileType Tag = 255 (FF) Type = SHORT N = 1 A general indication of the kind of data that is contained in this subfile. Currently defined values are: 1 = full resolution image data - ImageWidth, ImageLength, and StripOffsets are required fields; and 2 = reduced resolution image data - ImageWidth, ImageLength, and StripOffsets are required fields. It is further assumed that a reduced resolution image is a reduced version of the entire extent of the corresponding full resolution data. 3 = single page of a multi-page image (see the PageNumber tag description). Note that several image types can be found in a single TIFF file, with each subfile described by its own IFD. No default. Continued use of this field is not recommended. Writers should instead use the new and more general NewSubfileType field. Orientation Tag = 274 (112) Type = SHORT N = 1 1 = The 0th row represents the visual top of the image, and the 0th column represents the visual left hand side. 2 = The 0th row represents the visual top of the image, and the 0th column represents the visual right hand side. 3 = The 0th row represents the visual bottom of the image, and the 0th column represents the visual right hand side. 4 = The 0th row represents the visual bottom of the image, and the 0th column represents the visual left hand side. 5 = The 0th row represents the visual left hand side of the image, and the 0th column represents the visual top. 6 = The 0th row represents the visual right hand side of the image, and the 0th column represents the visual top. 7 = The 0th row represents the visual right hand side of the image, and the 0th column represents the visual bottom. 8 = The 0th row represents the visual left hand side of the image, and the 0th column represents the visual bottom. Default is 1. This field is recommended for private (non-interchange) use only. It is extremely costly for most readers to perform image rotation "on the fly," i.e., when importing and printing; and users of most desktop publishing applications do not expect a file imported by the application to be altered permanently in any way. Threshholding Tag = 263 (107) Type = SHORT N = 1 1 = a bilevel "line art" scan. BitsPerSample must be 1. 2 = a "dithered" scan, usually of continuous tone data such as photographs. BitsPerSample must be 1. 3 = Error Diffused. Default is Threshholding = 1. See also CellWidth, CellLength. 4) Private Fields An organization may wish to store information that is meaningful to only that organization in a TIFF file. Tags numbered 32768 or higher are reserved for that purpose. Upon request, the administrator will allocate and register a block of private tags for an organization, to avoid possible conflicts with other organizations. Tags are normally allocated in blocks of five. If that is not enough, feel free to ask for more. You do not need to tell the TIFF administrator or anyone else what you are going to use them for. Private enumerated values can be accommodated in a similar fashion. For example, you may wish to experiment with a new compression scheme within TIFF. Enumeration constants numbered 32768 or higher are reserved for private usage. Upon request, the administrator will allocate and register a block of enumerated values for a particular field (Compression, in our example), to avoid possible conflicts. Tags and values which are allocated in the private number range are not prohibited from being included in a future revision of this specification. Several such instances can be found in the TIFF specification. Do not choose your own tag numbers. If you do, it could cause serious problems some day. 5) Image File Format Issues In the quest to give users no reason NOT to buy a product, some scanning and image editing applications overwhelm users with an incredible number of "Save As..." options. Let's get rid of as many of these as we possibly can. For example, a single TIFF choice should suffice once most major readers are supporting the three TIFF compression schemes; then writers can always compress. And given TIFF's flexibility, including private tag and image editing support features, there does not seem to be any legitimate reason for continuing to write image files using proprietary formats. Along the same lines, there is no excuse for making a user have to know the file format of a file that is to be read by an application program. TIFF files, as well as most other file formats, contain sufficient information to enable software to automatically and reliably distinguish one type of file from another. 6) For Further Information Contact the Aldus Developers' Desk for sample TIFF files, source code fragments, and a list of features that are currently supported in Aldus products. The Aldus Developers' Desk is the current "TIFF administrator." Various TIFF related aids are found in Microsoft's Windows Developers Tookit for developers writing Windows applications. Finally, a number of scanner vendors are providing various TIFF services, such as helping to distribute the TIFF specification and answering TIFF questions. Contact the appropriate product manager or developer support service group. Appendix A: Tag Structure Rationale A file format is defined by both form (structure) and content. The content of TIFF consists of definitions of individual fields. It is therefore the content that we are ultimately interested in. The structure merely tells us how to find the fields. Yet the structure deserves serious consideration for a number of reasons that are not at all obvious at first glance. Since the structure described herein departs significantly from several other approaches, it may be useful to discuss the rationale behind it. The simplest, most straightforward structure for something like an image file is a positional format. In a positional scheme, the location of the data defines what the data means. For example, the field for "number of rows" might begin at byte offset 30 in the image file. This approach is simple and easy to implement and is perfect for static environments. But if a significant amount of ongoing change must be accommodated, subtle problems begin to appear. For example, suppose that a field must be superseded by a new, more general field. You could bump a version number to flag the change. Then new software has no problem doing something sensible with old data, and all old software will reject the new data, even software that didn't care about the old field. This may seem like no more than a minor annoyance at first glance, but causing old software to break more often than it would really need to can be very costly and, inevitably, causes much gnashing of teeth among customers. Furthermore, it can be avoided. One approach is to store a "valid" flag bit for each field. Now you don't have to bump the version number, as long as you can put the new field somewhere that doesn't disturb any of the old fields. Old software that didn't care about that old field anyway can continue to function. (Old software that did care will of course have to give up, but this is an unavoidable price to be paid for the sake of progress, barring total omniscience.) Another problem that crops up frequently is that certain fields are likely to make sense only if other fields have certain values. This is not such a serious problem in practice; it just makes things more confusing. Nevertheless, we note that the "valid" flag bits described in the previous paragraph can help to clarify the situation. Field-dumping programs can be very helpful for diagnostic purposes. A desirable characteristic of such a program is that it doesn't have to know much about what it is dumping. In particular, it would be nice if the program could dump ASCII data in ASCII format, integer data in integer format, and so on, without having to teach the program about new fields all the time. So maybe we should add a "data type" component to our fields, plus information on how long the field is, so that our dump program can walk through the fields without knowing what the fields "mean." But note that if we add one more component to each field, namely a tag that tells what the field means, we can dispense with the "valid" flag bits, and we can also avoid wasting space on the non-valid fields in the file. Simple image creation applications can write out several fields and be done. We have now derived the essentials of a tag-based image file format. Finally, a caveat. A tag based scheme cannot guarantee painless growth. But is does provide a useful tool to assist in the process. Appendix B: Data Compression - Scheme 2 Abstract This document describes a method for compressing bilevel data that is based on the CCITT Group 3 1D facsimile compression scheme. References 1. "Standardization of Group 3 facsimile apparatus for document transmission," Recommendation T.4, Volume VII, Fascicle VII.3, Terminal Equipment and Protocols for Telematic Services, The International Telegraph and Telephone Consultative Committee (CCITT), Geneva, 1985, pages 16 through 31. 2. "Facsimile Coding Schemes and Coding Control Functions for Group 4 Facsimile Apparatus," Recommendation T.6, Volume VII, Fascicle VII.3, Terminal Equipment and Protocols for Telematic Services, The International Telegraph and Telephone Consultative Committee (CCITT), Geneva, 1985, pages 40 through 48. We do not believe that these documents are necessary in order to implement Compression=2. We have included (verbatim in most places) all the pertinent information in this Appendix. However, if you wish to order the documents, you can write to ANSI, Attention: Sales, 1430 Broadway, New York, N.Y., 10018. Ask for the publication listed above -it contains both Recommendation T.4 and T.6. Relationship to the CCITT Specifications The CCITT Group 3 and Group 4 specifications describe communications protocols for a particular class of devices. They are not by themselves sufficient to describe a disk data format. Fortunately, however, the CCITT coding schemes can be readily adapted to this different environment. The following is one such adaptation. Most of the language is copied directly from the CCITT specifications. Coding Scheme A line (row) of data is composed of a series of variable length code words. Each code word represents a run length of either all white or all black. (Actually, more than one code word may be required to code a given run, in a manner described below.) White runs and black runs alternate. In order to ensure that the receiver (decompressor) maintains color synchronization, all data lines will begin with a white run length code word set. If the actual scan line begins with a black run, a white run length of zero will be sent (written). Black or white run lengths are defined by the code words in Tables 1 and 2. The code words are of two types: Terminating code words and Make-up code words. Each run length is represented by zero or more Make-up code words followed by exactly one Terminating code word. Run lengths in the range of 0 to 63 pels (pixels) are encoded with their appropriate Terminating code word. Note that there is a different list of code words for black and white run lengths. Run lengths in the range of 64 to 2623 (2560+63) pels are encoded first by the Make-up code word representing the run length that is nearest to, not longer than, that required. This is then followed by the Terminating code word representing the difference between the required run length and the run length represented by the Make-up code. Run lengths in the range of lengths longer than or equal to 2624 pels are coded first by the Make-up code of 2560. If the remaining part of the run (after the first Make-up code of 2560) is 2560 pels or greater, additional Make-up code(s) of 2560 are issued until the remaining part of the run becomes less than 2560 pels. Then the remaining part of the run is encoded by Terminating code or by Make-up code plus Terminating code, according to the range mentioned above. It is considered an unrecoverable error if the sum of the run lengths for a line does not equal the value of the ImageWidth field. New rows always begin on the next available byte boundary. No EOL code words are used. No fill bits are used, except for the ignored bits at the end of the last byte of a row. RTC is not used. Table 1/T.4 Terminating codes White Black run Code run Code length word length word ---- ---- ------ ---- 0 00110101 0 0000110111 1 000111 1 010 2 0111 2 11 3 1000 3 10 4 1011 4 011 5 1100 5 0011 6 1110 6 0010 7 1111 7 00011 8 10011 8 000101 9 10100 9 000100 10 00111 10 0000100 11 01000 11 0000101 12 001000 12 0000111 13 000011 13 00000100 14 110100 14 00000111 15 110101 15 000011000 16 101010 16 0000010111 17 101011 17 0000011000 18 0100111 18 0000001000 19 0001100 19 00001100111 20 0001000 20 00001101000 21 0010111 21 00001101100 22 0000011 22 00000110111 23 0000100 23 00000101000 24 0101000 24 00000010111 25 0101011 25 00000011000 26 0010011 26 000011001010 27 0100100 27 000011001011 28 0011000 28 000011001100 29 00000010 29 000011001101 30 00000011 30 000001101000 31 00011010 31 000001101001 32 00011011 32 000001101010 33 00010010 33 000001101011 34 00010011 34 000011010010 35 00010100 35 000011010011 36 00010101 36 000011010100 37 00010110 37 000011010101 38 00010111 38 000011010110 39 00101000 39 000011010111 40 00101001 40 000001101100 41 00101010 41 000001101101 42 00101011 42 000011011010 43 00101100 43 000011011011 44 00101101 44 000001010100 45 00000100 45 000001010101 46 00000101 46 000001010110 47 00001010 47 000001010111 48 00001011 48 000001100100 49 01010010 49 000001100101 50 01010011 50 000001010010 51 01010100 51 000001010011 52 01010101 52 000000100100 53 00100100 53 000000110111 54 00100101 54 000000111000 55 01011000 55 000000100111 56 01011001 56 000000101000 57 01011010 57 000001011000 58 01011011 58 000001011001 59 01001010 59 000000101011 60 01001011 60 000000101100 61 00110010 61 000001011010 62 00110011 62 000001100110 63 00110100 63 000001100111 Table 2/T.4 Make-up codes White Black run Code run Code length word length word ------ ---- ------ ---- 64 11011 64 0000001111 128 10010 128 000011001000 192 010111 192 000011001001 256 0110111 256 000001011011 320 00110110 320 000000110011 384 00110111 384 000000110100 448 01100100 448 000000110101 512 01100101 512 0000001101100 576 01101000 576 0000001101101 640 01100111 640 0000001001010 704 011001100 704 0000001001011 768 011001101 768 0000001001100 832 011010010 832 0000001001101 896 011010011 896 0000001110010 960 011010100 960 0000001110011 1024 011010101 1024 0000001110100 1088 011010110 1088 0000001110101 1152 011010111 1152 0000001110110 1216 011011000 1216 0000001110111 1280 011011001 1280 0000001010010 1344 011011010 1344 0000001010011 1408 011011011 1408 0000001010100 1472 010011000 1472 0000001010101 1536 010011001 1536 0000001011010 1600 010011010 1600 0000001011011 1664 011000 1664 0000001100100 1728 010011011 1728 0000001100101 EOL 000000000001 EOL 000000000001 Additional make-up codes White and Black Make-up run code length word ------ ---- 1792 00000001000 1856 00000001100 1920 00000001101 1984 000000010010 2048 000000010011 2112 000000010100 2176 000000010101 2240 000000010110 2304 000000010111 2368 000000011100 2432 000000011101 2496 000000011110 2560 000000011111 Appendix C: Data Compression - Scheme 32773 - "PackBits" Abstract This document describes a simple compression scheme for bilevel scanned and paint type files. Motivation The TIFF specification defines a number of compression schemes. Compression type 1 is really no compression, other than basic pixel packing. Compression type 2, based on CCITT 1D compression, is powerful, but not trivial to implement. Compression type 5 is typically very effective for most bilevel images, as well as many deeper images such as palette color and grayscale images, but is also not trivial to implement. PackBits is a simple but often effective alternative. Description Several good schemes were already in use in various settings. We somewhat arbitrarily picked the Macintosh PackBits scheme. It is byte oriented, so there is no problem with word alignment. And it has a good worst case behavior (at most 1 extra byte for every 128 input bytes). For Macintosh users, there are toolbox utilities PackBits and UnPackBits that will do the work for you, but it is easy to implement your own routines. A pseudo code fragment to unpack might look like this: Loop until you get the number of unpacked bytes you are expecting: Read the next source byte into n. If n is between 0 and 127 inclusive, copy the next n+1 bytes literally. Else if n is between -127 and -1 inclusive, copy the next byte -n+1 times. Else if n is 128, noop. Endloop In the inverse routine, it's best to encode a 2-byte repeat run as a replicate run except when preceded and followed by a literal run, in which case it's best to merge the three into one literal run. Always encode 3-byte repeats as replicate runs. So that's the algorithm. Here are some other rules: o Each row must be packed separately. Do not compress across row boundaries. o The number of uncompressed bytes per row is defined to be (ImageWidth + 7) / 8. If the uncompressed bitmap is required to have an even number of bytes per row, decompress into word- aligned buffers. o If a run is larger than 128 bytes, simply encode the remainder of the run as one or more additional replicate runs. When PackBits data is uncompressed, the result should be interpreted as per compression type 1 (no compression). Appendix D Appendix D has been deleted. It formerly contained guidelines for passing TIFF files on the Microsoft Windows Clipboard. This was judged to not be a good idea, in light of the ever-increasing size of scanned images. Applications are instead encouraged to employ file-based mechanisms to exchange TIFF data. Aldus- PageMaker, for example, implements a "File Place" command to allow TIFF files to be imported. Appendix E: Numerical List of TIFF Tags NewSubfileType Tag = 254 (FE) Type = LONG N = 1 SubfileType Tag = 255 (FF) Type = SHORT N = 1 ImageWidth Tag = 256 (100) Type = SHORT or LONG N = 1 ImageLength Tag = 257 (101) Type = SHORT or LONG N = 1 BitsPerSample Tag = 258 (102) Type = SHORT N = SamplesPerPixel Compression Tag = 259 (103) Type = SHORT N = 1 PhotometricInterpretation Tag = 262 (106) Type = SHORT N = 1 Threshholding Tag = 263 (107) Type = SHORT N = 1 CellWidth Tag = 264 (108) Type = SHORT N = 1 CellLength Tag = 265 (109) Type = SHORT N = 1 FillOrder Tag = 266 (10A) Type = SHORT N = 1 DocumentName Tag = 269 (10D) Type = ASCII ImageDescription Tag = 270 (10E) Type = ASCII Make Tag = 271 (10F) Type = ASCII Model Tag = 272 (110) Type = ASCII StripOffsets Tag = 273 (111) Type = SHORT or LONG N = StripsPerImage for PlanarConfiguration equal to 1. = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2 Orientation Tag = 274 (112) Type = SHORT N = 1 SamplesPerPixel Tag = 277 (115) Type = SHORT N = 1 RowsPerStrip Tag = 278 (116) Type = SHORT or LONG N = 1 StripByteCounts Tag = 279 (117) Type = LONG or SHORT N = StripsPerImage for PlanarConfiguration equal to 1. = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2. MinSampleValue Tag = 280 (118) Type = SHORT N = SamplesPerPixel MaxSampleValue Tag = 281 (119) Type = SHORT N = SamplesPerPixel XResolution Tag = 282 (11A) Type = RATIONAL N = 1 YResolution Tag = 283 (11B) Type = RATIONAL N = 1 PlanarConfiguration Tag = 284 (11C) Type = SHORT N = 1 PageName Tag = 285 (11D) Type = ASCII XPosition Tag = 286 (11E) Type = RATIONAL YPosition Tag = 287 (11F) Type = RATIONAL FreeOffsets Tag = 288 (120) Type = LONG FreeByteCounts Tag = 289 (121) Type = LONG GrayResponseUnit Tag = 290 (122) Type = SHORT N = 1 GrayResponseCurve Tag = 291 (123) Type = SHORT N = 2**BitsPerSample Group3Options Tag = 292 (124) Type = LONG N = 1 Group4Options Tag = 293 (125) Type = LONG N = 1 ResolutionUnit Tag = 296 (128) Type = SHORT N = 1 PageNumber Tag = 297 (129) Type = SHORT N = 2 ColorResponseCurves Tag = 301 (12D) Type = SHORT N = 3 * (2**BitsPerSample) Software Tag = 305 (131) Type = ASCII DateTime Tag = 306 (132) Type = ASCII N = 20 Artist Tag = 315 (13B) Type = ASCII HostComputer Tag = 316 (13C) Type = ASCII Predictor Tag = 317 (13D) Type = SHORT N = 1 WhitePoint Tag = 318 (13E) Type = RATIONAL N = 2 PrimaryChromaticities Tag = 319 (13F) Type = RATIONAL N = 6 ColorMap Tag = 320 (140) Type = SHORT N = 3 * (2**BitsPerSample) Appendix F: Data Compression - Scheme 5 - LZW Compression Abstract This document describes an adaptive compression scheme for raster images. Reference Terry A. Welch, "A Technique for High Performance Data Compression", IEEE Computer, vol. 17 no. 6 (June 1984). Describes the basic Lempel-Ziv & Welch (LZW) algorithm. The author's goal in the article is to describe a hardware-based compressor that could be built into a disk controller or database engine, and used on all types of data. There is no specific discussion of raster images. We intend to give sufficient information in this Appendix so that the article is not required reading. Requirements A compression scheme with the following characteristics should work well in a desktop publishing environment: o Must work well for images of any bit depth, including images deeper than 8 bits per sample. o Must be effective: an average compression ratio of at least 2:1 or better. And it must have a reasonable worst-case behavior, in case something really strange is thrown at it. o Should not depend on small variations between pixels. Palette color images tend to contain abrupt changes in index values, due to common patterning and dithering techniques. These abrupt changes do tend to be repetitive, however, and the scheme should make use of this fact. o For images generated by paint programs, the scheme should not depend on a particular pattern width. 8x8 pixel patterns are common now, but we should not assume that this situation will not change. o Must be fast. It should not take more than 5 seconds to decompress a 100K byte grayscale image on a 68020- or 386-based computer. Compression can be slower, but probably not by more than a factor of 2 or 3. o The level of implementation complexity must be reasonable. We would like something that can be implemented in no more than a couple of weeks by a competent software engineer with some experience in image processing. The compiled code for compression and decompression combined should be no more than about 10K. o Does not require floating point software or hardware. The following sections describe an algorithm based on the "LZW" (Lempel-Ziv & Welch) technique that meets the above requirements. In addition meeting our requirements, LZW has the following characteristics: o LZW is fully reversible. All information is preserved. But if noise or information is removed from an image, perhaps by smoothing or zeroing some low-order bitplanes, LZW compresses images to a smaller size. Thus, 5-bit, 6-bit, or 7-bit data masquerading as 8-bit data compresses better than true 8-bit data. Smooth images also compress better than noisy images, and simple images compress better than complex images. o On a 68082- or 386-based computer, LZW software can be written to compress at between 30K and 80K bytes per second, depending on image characteristics. LZW decompression speeds are typically about 50K bytes per second. o LZW works well on bilevel images, too. It always beats PackBits, and generally ties CCITT 1D (Modified Huffman) compression, on our test images. Tying CCITT 1D is impressive in that LZW seems to be considerably faster than CCITT 1D, at least in our implementation. o Our implementation is written in C, and compiles to about 2K bytes of object code each for the compressor and decompressor. o One of the nice things about LZW is that it is used quite widely in other applications such as archival programs, and is therefore more of a known quantity. The Algorithm Each strip is compressed independently. We strongly recommend that RowsPerStrip be chosen such that each strip contains about 8K bytes before compression. We want to keep the strips small enough so that the compressed and uncompressed versions of the strip can be kept entirely in memory even on small machines, but large enough to maintain nearly optimal compression ratios. The LZW algorithm is based on a translation table, or string table, that maps strings of input characters into codes. The TIFF implementation uses variable-length codes, with a maximum code length of 12 bits. This string table is different for every strip, and, remarkably, does not need to be kept around for the decompressor. The trick is to make the decompressor automatically build the same table as is built when compressing the data. We use a C-like pseudocode to describe the coding scheme: InitializeStringTable(); WriteCode(ClearCode); Omega = the empty string; for each character in the strip { K = GetNextCharacter(); if Omega+K is in the string table { Omega = Omega+K; /* string concatenation */ } else { WriteCode (CodeFromString(Omega)); AddTableEntry(Omega+K); Omega = K; } } /* end of for loop */ WriteCode (CodeFromString(Omega)); WriteCode (EndOfInformation); That's it. The scheme is simple, although it is fairly challenging to implement efficiently. But we need a few explanations before we go on to decompression. The "characters" that make up the LZW strings are bytes containing TIFF uncompressed (Compression=1) image data, in our implementation. For example, if BitsPerSample is 4, each 8-bit LZW character will contain two 4-bit pixels. If BitsPerSample is 16, each 16-bit pixel will span two 8-bit LZW characters. (It is also possible to implement a version of LZW where the LZW character depth equals BitsPerSample, as was described by Draft 2 of Revision 5.0. But there is a major problem with this approach. If BitsPerSample is greater than 11, we can not use 12-bit-maximum codes, so that the resulting LZW table is unacceptably large. Fortunately, due to the adaptive nature of LZW, we do not pay a significant compression ratio penalty for combining several pixels into one byte before compressing. For example, our 4-bit sample images compressed about 3 percent worse, and our 1-bit images compressed about 5 percent better. And it is easier to write an LZW compressor that always uses the same character depth than it is to write one which can handle varying depths.) We can now describe some of the routine and variable references in our pseudocode: InitializeStringTable() initializes the string table to contain all possible single-character strings. There are 256 of them, numbered 0 through 255, since our characters are bytes. WriteCode() writes a code to the output stream. The first code written is a Clear code, which is defined to be code #256. Omega is our "prefix string." GetNextCharacter() retrieves the next character value from the input stream. This will be number between 0 and 255, since our characters are bytes. The "+" signs indicate string concatenation. AddTableEntry() adds a table entry. (InitializeStringTable() has already put 256 entries in our table. Each entry consists of a single-character string, and its associated code value, which is, in our application, identical to the character itself. That is, the 0th entry in our table consists of the string <0>, with corresponding code value of <0>, the 1st entry in the table consists of the string <1>, with corresponding code value of <1>, ..., and the 255th entry in our table consists of the string <255>, with corresponding code value of <255>.) So the first entry that we add to our string table will be at position 256, right? Well, not quite, since we will reserve code #256 for a special "Clear" code, and code #257 for a special "EndOfInformation" code that we will write out at the end of the strip. So the first multiple-character entry added to the string table will be at position 258. Let's try an example. Suppose we have input data that looks like: Pixel 0: <7> Pixel 1: <7> Pixel 2: <7> Pixel 3: <8> Pixel 4: <8> Pixel 5: <7> Pixel 6: <7> Pixel 7: <6> Pixel 8: <6> First, we read Pixel 0 into K. OmegaK is then simply <7>, since Omega is the empty string at this point. Is the string <7> already in the string table? Of course, since all single character strings were put in the table by InitializeStringTable(). So set Omega equal to <7>, and go to the top of the loop. Read Pixel 1 into K. Does OmegaK (<7><7>) exist in the string table? No, so we get to do some real work. We write the code associated with Omega to output (write <7> to output), and add OmegaK (<7><7>) to the table as entry 258. Store K (<7>) into Omega. Note that although we have added the string consisting of Pixel 0 and Pixel 1 to the table, we "re-use" Pixel 1 as the beginning of the next string. Back at the top of the loop. We read Pixel 2 into K. Does OmegaK (<7><7>) exist in the string table? Yes, the entry we just added, entry 258, contains exactly <7><7>. So we just add K onto the end of Omega, so that Omega is now <7><7>. Back at the top of the loop. We read Pixel 3 into K. Does OmegaK (<7><7><8>) exist in the string table? No, so write the code associated with Omega (<258>) to output, and add OmegaK to the table as entry 259. Store K (<8>) into Omega. Back at the top of the loop. We read Pixel 4 into K. Does OmegaK (<8><8>) exist in the string table? No, so write the code associated with Omega (<8>) to output, and add OmegaK to the table as entry 260. Store K (<8>) into Omega. Continuing, we get the following results: After reading: We write to output: And add table entry: Pixel 0 Pixel 1 <7> 258: <7><7> Pixel 2 Pixel 3 <258> 259: <7><7><8> Pixel 4 <8> 260: <8><8> Pixel 5 <8> 261: <8><7> Pixel 6 Pixel 7 <258> 262: <7><7><6> Pixel 8 <6> 263: <6><6> WriteCode() also requires some explanation. The output code stream, <7><258><8><8><258><6>... in our example, should be written using as few bits as possible. When we are just starting out, we can use 9-bit codes, since our new string table entries are greater than 255 but less than 512. But when we add table entry 512, we must switch to 10-bit codes. Likewise, we switch to 11-bit codes at 1024, and 12-bit codes at 2048. We will somewhat arbitrarily limit ourselves to 12-bit codes, so that our table can have at most 4096 entries. If we push it any farther, tables tend to get too large. What happens if we run out of room in our string table? This is where the afore-mentioned Clear code comes in. As soon as we use entry 4094, we write out a (12-bit) Clear code. (If we wait any longer to write the Clear code, the decompressor might try to interpret the Clear code as a 13-bit code.) At this point, the compressor re-initializes the string table and starts writing out 9-bit codes again. Note that whenever you write a code and add a table entry, Omega is not left empty. It contains exactly one character. Be careful not to lose it when you write an end-of-table Clear code. You can either write it out as a 12-bit code before writing the Clear code, in which case you will want to do it right after adding table entry 4093, or after the clear code as a 9-bit code. Decompression gives the same result in either case. To make things a little simpler for the decompressor, we will require that each strip begins with a Clear code, and ends with an EndOfInformation code. Every LZW-compressed strip must begin on a byte boundary. It need not begin on a word boundary. LZW compression codes are stored into bytes in high-to-low-order fashion, i.e., FillOrder is assumed to be 1. The compressed codes are written as bytes, not words, so that the compressed data will be identical regardless of whether it is an "II" or "MM" file. Note that the LZW string table is a continuously updated history of the strings that have been encountered in the data. It thus reflects the characteristics of the data, providing a high degree of adaptability. LZW Decoding The procedure for decompression is a little more complicated, but still not too bad: while ((Code = GetNextCode()) != EoiCode) { if (Code == ClearCode) { InitializeTable(); Code = GetNextCode(); if (Code == EoiCode) break; WriteString(StringFromCode(Code)); OldCode = Code; } /* end of ClearCode case */ else { if (IsInTable(Code)) { WriteString(StringFromCode(Code)); AddStringToTable(StringFromCode(OldCode)+ FirstChar(StringFromCode(Code))); OldCode = Code; } else { OutString = StringFromCode(OldCode) + FirstChar(StringFromCode(OldCode)); WriteString(OutString); AddStringToTable(OutString); OldCode = Code; } } /* end of not-ClearCode case */ } /* end of while loop */ The function GetNextCode() retrieves the next code from the LZW- coded data. It must keep track of bit boundaries. It knows that the first code that it gets will be a 9-bit code. We add a table entry each time we get a code, so GetNextCode() must switch over to 10-bit codes as soon as string #511 is stored into the table. The function StringFromCode() gets the string associated with a particular code from the string table. The function AddStringToTable() adds a string to the string table. The "+" sign joining the two parts of the argument to AddStringToTable indicate string concatenation. StringFromCode() looks up the string associated with a given code. WriteString() adds a string to the output stream. When SamplesPerPixel Is Greater Than 1 We have so far described the compression scheme as if SamplesPerPixel were always 1, as will be be the case with palette color and grayscale images. But what do we do with RGB image data? Tests on our sample images indicate that the LZW compression ratio is nearly identical regardless of whether PlanarConfiguration=1 or PlanarConfiguration=2, for RGB images. So use whichever configuration you prefer, and simply compress the bytes in the strip. It is worth cautioning that compression ratios on our test RGB images were disappointing low: somewhere between 1.1 to 1 and 1.5 to 1, depending on the image. Vendors are urged to do what they can to remove as much noise from their images as possible. Preliminary tests indicate that significantly better compression ratios are possibl